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REMARKS/ARGUMENTS 

In an Office Action dated April 19, 2005, claims 20-22, 31, 35, 39 and 42 were 
rejected under § 102 over Wyatt; and the remaining claims were rejected under § 103 
over Wyatt and various other references. Applicants submit that the claims are allowable. 
Claims 15-19, 29 and 30 

Claims 15-19, 29 and 30 are cancelled in the Amendment without prejudice. 
Applicants reserve the right to prosecute the claims in a continuation application. 
Applicants further note that arguments have been made to the rejections of the similar 
method and apparatus claims and could have been made to these article of manufacture 
claims, so the cancellation is not responsive to the substantive rejection in the Office 
Action. 

Further General Background Discussion 

To assist in the handling of the application, Applicants believe some further 
general background discussion will be helpful. In the prior discussion Applicants 
provided a brief overview to compare Fibre Channel and Ethernet. Based on a review of 
the cited references, a further discussion is considered proper. Many of the claims in the 
present case generally relate to in order delivery of frames over two parallel links. The 
point of concern is in order dehv^xof frames, not in order transmission o f frames. 
While it may appear at first blush that the phrases are equivalent, such is not the case. 
Just because frames are transmitted in order over two parallel links does not guarantee 
that they are delivered in order. If one link is one meter long and one link is one 
kilometer long, and 2 kbit frames are continuously being sent down each link at 2 Gb/s, at 
least two and more likely three frames will be received from the shorter link before the 
first frame is received from the longer link. Assuming a 2 kbit frame and 2 Gb/s links, 
each frame is one microsecond long. For a 1 km link, the speed of light requires over 
three microseconds and any actual transmission is slower. Thus if two packets were 
simultaneously transmitted on both links, the first frame would be received over the 
shorter link, as would the next two frames, before the first frame was received over the 
longer link. Thus in order transmission is clearly not equivalent to in order delivery. 
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Therefore merely mentioning in order transmission does not teach or suggest in order 
delivery. Systems according to the present invention can perform true trunkiiig with in 
order receipt of frames across the links in the trunk. The claims cover various aspects of 
the present invention. 

5 102 Rejections 

Claims 20-22, 31, 35, 39 and 42 were rejected under § 102 over Wyatt. 
Applicants respectfully traverse the rejection. 

Claim 20 

Claim 20 requires "the transmit port routing frames received at the first switch 
across the group to the second switch." The Office Action referenced a section in the 
Summary of Wyatt as showing this requirement. The two relevant sentences are "trunk 
port selector logic in the switch selects a trunk port entry dependent on the flow hash. 
The trunk port entry selects the physical link M 

Applicants submit that reference to the Detailed Description of Wyatt places the 
physical link selection logic elsewhere than the transmit port as required by the claim. 
Specifically, Wyatt places the logic in the ingress or receive portion, not even the 
transmit or egress portion, much less a transmit port as required . See Fig. IB, 
forwarding logic 128, which is introduced at p. 2, H 26. Further details of the forwarding 
logic 128 is provided in Fig. 3, whose description is from p. 3, H 40 to p. 4, end of H 48. 
Thus the details of Wyatt clarify the summary used by the Office Action and clearly 
indicate that Wyatt does not teach or suggest the claim requirements. 

Applicants thus submit that Wyatt does not show a required claim element of 
claim 20 and those dependent therefrom. 

Claim 31 

Claim 31 requires "transmitting the queued frames from the plurality of first ports 
to the plurality of second ports so that the frames are received at the second ports in order 
as received at the first switch." The Office Action referenced p. 2, U 25 of Wyatt stating 
that the data flow is transmitted to the destination in the order that they are received. The 
full quote of Wyatt is "data packets }40a-c for the data flow from source 1 02a to 
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destination 112c are transmitted to the destination 112 in the order that they are received 
by the switch 100/' 

Thus the claim requires being received in order while Wyatt discloses being 
transmitted in order. As discussed above, these are not equivalent. In order transmission 
does not equate to in order reception, and does not suggest it either. 

Applicants thus submit that Wyatt does not teach or suggest a required claim 
element of claim 3 1 and those dependent therefrom. 

Claims 35. 39 and 42 

Each of these claims similarly requires 'transmitting logic for transmitting the 
queued frames from said two ports over said two links so that the frames are received at 
said two ports of said second network device in order/* As discussed with respect to 
claim 3 1 , Wyatt only discloses transmission in order, not reception in order, thus not 
teaching or suggesting a required claim element. 

Applicants submit that claims 35-45 are allowable over Wyatt. 

103 Rejections 

The remaining claims were rejected over Wyatt and various references including 
Muller, O'Keefe, Bertin and Kadambi. Applicants respectfully traverse the rejections. 

Claim 1 

Applicants respectfully submit that the tmnking master ports required in claim 1 
are not shown, taught or suggested by the combination of Muller, Wyatt and O'Keefe. 

Claim 1 requires that the trunking master control the frames routed over the 
trunked group. The Office Action references col 1, lines 37-50 of O'Keefe as suggesting 
this claim element. Applicants respectfully disagree. 

The relevant portions of the citation read: 

Jackets which are destined for a remote device that is 
linked via a trunk are directed to the bridge port of that trunk and 
simple low level circuitry decides, . . which physical port of the 
trunk should be used for forwarding the packet to the remote 
device/ 1 
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This is explained in more detail in Fig, 2 of O'Keefe and col. 4, lines 23-46, 
Referring to Fig- 2 of O'Keefe, the switch logic 8 selects the destination port, the BP port. 
The hashing logic 9 then selects a particular port 6 or 7 for the packet. Applicants 
specifically note that the hashing logic 9 is not a portion of the ports 6 or 7 and thus does 
not meet the requirements of claim 1 where the trunking master ports control the frame 
routing over the trunked group. 

Applicants further note with reference to Fig. 2 of O'Keefe that the designation 
"Bridge Port** or "Master Port" is a "logical" port. A logical port is just that, logical, not 
physical. Because it is just a logical port, it cannot perform the required physical acts of 
controlling the routing of the frames. That is done, as shown in Fig. 2, by hashing logic 9 
which is not part of the actual ports 6 and 7. 

Therefore, while O'Keefe may use similar language, a closer inspection reveals 
that O'Keefe actually teaches away from the claim requirements. Thus Applicants 
respectfully submit that claim 1 and those dependent therefrom are allowable over the 
combination of Muller, Wyatt and O'Keefe. 

Claim 2 

The Office Action generally referenced ports in Fig. 1 of Muller to reject claim 2. 
Applicants respectfully traverse this rejection. Muller describes Ethernet connections. 
See col. 3, lines 49-51 and the frequent references to MAC addresses, including col. 1, 
lines 35-40. The claimed E_ports of claim 2 are Fibre Channel ports. Just because the 
two environments have some common factors does not make them sufficiently equivalent 
to support a rejection. There axe numerous differences between Ethernet and Fibre 
Channel as well, one being the requirement for in order delivery for Fibre Channel but 
not for Ethernet. As that difference is much more relevant than the very high level 
similarities mentioned on the Office Action, Applicants submit that the rejection of claim 
2 under § 103 is improper. 

Claims 11 and 17 

Applicants first note that for claims 1 1 and 17 an input port has been defined to be 
a master transmit port. This contradicts the elements of Muller defined by the Office 
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Action as tnmking master ports in claim 1 (output ports as best understood) and claim 1 0 
(cleaxly output ports). It is a fundamental point that the definition of an item cannot 
change between claims. Thus this forms a first reason the rejections of claims 1 1 and 17 
are improper. 

Secondly, claims 1 1 and 17 require enabling a frame to be received at the second 
switch with "in-order" delivery. The Office Action does not properly address this 
required claim limitation. The Office Action states that Wyatt discloses in order 
transmission, but that is not equivalent to the required in order delivery, as discussed at 
length above. Thus Applicants submit that Muller and Wyatt do not show "in-order" 
delivery. 

Claim 13 

Claim 1 3 requires a trunking master port comprising a receive port queuing 
frames received over the trunk group. The Office Action references p. 2, T[ 24 of Wyatt 
as teaching this element. Applicants respectfully disagree. 

Applicants first note that Wyatt is discussing an "egress port queue " An egress 
port is a transmit port, not a receive port as required by the claim. This is buttressed by 
Wyatt placing the egress port queues 130 in a block for the packet storage manager 106, 
which is totally separate from the ingress ports engine 104. Thus the queuing is not being 
done by a port but by centralized logic, in contrast to the claim which requires the port to 
queue the frames. 

Applicants respectfully submit that the combination does not teach or suggest 
required elements of claim 13 and is allowable. 

Claim 3 

Claim 3 requires two ports on separate switches to exchange link parameters and 
then determining if two identifiers exist, one higher than the other. Applicants submit 
that none of Muller, Wyatt, O'Keefe or Kadambi show these claim requirements. 
Exchanging link parameters (ELP) is a process wherein there is a communication 
between the two connected ports of the two separate switches. See Fig. 4 of the present 
application and pages 49 - 53 of the FC-SW specification provided in the Information 
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Disclosure Statement. Neither Muller nor Kadambi show any similar communication 
process. The portions or operations mentioned in the Office Action are all internal to the 
given switches in Muller and Kadambi. There is no inter-switch communication like that 
required in the claim. 

Then there clearly cannot be any teaching or suggestion of comparing identifiers 
as there is not even the requisite ELP. 

Therefore Applicants submit claim 3 is allowable, both for being dependent on 
allowable claim 1 and for the reasons mentioned here. 

Claim 4 

Claim 4 is allowable as being dependent on allowable claims 1 and 3. In addition, 
as stated above, a WWN is a Fibre Channel term Both Muller and Kadambi are 
Ethernet-based disclosures where the identifiers would be MAC addresses and therefore 
do not teach or suggest the identifiers being WWNs, 

Claim 5 

Claim 5 was rejected over Muller, Wyatt, O'Keefe and Bertin. Applicants 
respectfully traverse the rejection. 

As a first point, while Bertin may maintain propagation delay values for each link, 
this does not teach or suggest determining one way skew values for links associated with 
the trunked group, Bertin's concern is overall transit time or variation. Bertin develops 
each possible path a node at a time, checking to see if the path still meets requirements. 
See col. 12, line 59 to col. 13, line 8. Bertin never compares the propagation delay of one 
link versus the other in making a routing selection. That type of comparison is simply 
not relevant to Bertin. So, while the data may be present for Bertin to theoretically 
determine link skew, there is no suggestion or teaching of a reason to do so. Such 
suggestion would come only in hindsight where the teachings and claims of the present 
application are considered. 

Further, there is no suggestion in either Muller, Wyatt, O'Keefe or Bertin to use a 
skew value to add a port to a trunk group. As noted above, Muller does not indicate how 
ports are added to a trunk group, much less using a skew value in that determination. 
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O'Keefe may have some mention of adding ports to a trunk group but it involves only 
frame address detection, not a skew value, Berlin does not add this teaching or 
suggestion because Bertin does not involve trunks and never suggests determining a link 
skew value. 

Claim 6 

Claim 6 is allowable as being based on allowable claims 1 and 5, Further, the 
arguments of claim 5 relate here. Bertin may maintain link speeds but does not suggest 
comparing two speeds of links for a trunking determination. The skew arguments from 
claim 5 apply directly. Further, the arguments about Muller not teaching how a port is 
added to a group applies. Muller merely is related to routing for trunks, not assigning to 
trunks. Similarly O'Keefe does not use link speed as a factor in adding a port to a trunk 
group. 

Claim 7 

Claim 7 is allowable as being based on allowable claims 1 and 5. 
Claim 14 

As noted above, Muller does not indicate how or when ports are added to a 
tmnked group. Muller simply knows the ports are in a trunked group. Bertin does not 
teach trunks and so would not suggest when to add ports to a trunked group. In O'Keefe 
ports are added to trunk groups based on addresses in received frames. As this could not 
happen before the relevant links and ports are initialized, O'Keefe cannot teach or 
suggest claim 14. Therefore Applicants submit claim 14 is allowable, 

Claim 23 

Applicants traverse the rejection of claim 23. In addition to the requirements of 
claim 20 discussed above, claim 23 requires a timer used in conjunction with a list 
associated with the transmit port to ensure "in-order" delivery of frames. Applicants 
request reference to paragraph 5 1 of the present application. In the preferred embodiment 
the timers bind or block transmit operations until the relevant link skew is 
accommodated. A mere timer to measure propagation delay does nothing like this. A 
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propagation delay timer would do nothing to ensure "in-order" delivery. Thus the mere 
presence of a timer to measure propagation delay does not begin to teach or suggest 
various requirements of claim 23. 

Claim 24 

Applicants traverse this rejection. The Office Action defines the timer in claim 23 
to be for maintaining propagation delay and then in claim 24 the Office Action references 
a time to live parameter. These two items in Bertin are completely unrelated, yet the 
Office Action attempts to use them in some combination. As claim 24 is dependent on 
claim 23 and further defines the timer of claim 23, this reference to a completely different 
item is improper and the rejection must be withdrawn. 

Claim 25 

Please refer to the arguments made with respect to claim 2. 
Claims 32/36. 40 and 43 

Claims 32, 36, 40 and 43 require determining skew values for the links and using 
those skew values to control timing of the transmission. The Office Action cites Bertin 
for teaching propagation delay, which is equated to skew value. The Office Action also 
cites portions of Bertin as showing a quality of service requirement with various 
parameters. 

As a first point, while Bertin may maintain propagation delay values for each link, 
this does not teach or suggest determining one way skew values for links associated with 
the trunked group. Bertin's concern is overall transit time or variation. Bertin develops 
each possible path a node at a time, checking to see if the path still meets requirements. 
See col. 12, line 59 to col. 13, line 8. Bertin never compares the propagation delay of one 
link versus the other in making a routing selection. That type of comparison is simply 
not relevant to Bertin. So, while the data may be present for Bertin to theoretically 
determine link skew, there is no suggestion or teaching of a reason to do so. Such 
suggestion would come only in hindsight where the teachings and claims of the present 
application are considered. 
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As to the quality of service portion of Bertin, Applicants submit this is not 
relevant to the claim requirement relating to timing of the transmission. Berlin relates to 
route selection, so the quality of service parameters listed apply to route selection, not 
timing of transmissions over a link. The concepts are not related. 

Applicants submit that claims 32, 36, 40 and 43 are allowable. 

Claims 33 n 37 anH AA 

Claims 33, 37 and 44 all require the skew values to be one way skew values 
Bertin was cited as teaching this element. 

As noted above, while Bertin may maintain propagation delay values for 
each link, this does not teach or suggest determining one way skew values for links 
associated with the trunked group. Berlin's concern is overall transit time or variation. 
Bertin develops each possible path a node at a time, checking to see if the path still meets 
requirements. See col. 12, line 59 to col. 13, line 8. Bertin never compares the 
propagation delay of one link versus the other in making a routing selection. That type of 
comparison is simply not relevant to Bertin. So, while the data may be present for Bertin 
to theoretically determine link skew, there is no suggestion or teaching of a reason to do 
so. Such suggestion would come only in hindsight where the teachings and claims of the 
present application are considered. 

Applicants respectfully submit that claims 33, 37 and 44 are allowable. 
Claims 34. 38, 41 and 45 

Claims 34, 38, 41 and 45, require Fibre Channel devices. The Office Action 
simply equated Ethernet and Fibre Channel. 

Muller describes Ethernet connections. Just because the two environments have 
some common factors does not make them sufficiently equivalent to support a rejection. 
There are numerous differences between Ethernet and Fibre Channel as well, one being 
the requirement for in order delivery for Fibre Channel but not for Ethernet. As that 
difference is much more relevant than the very high level similarities mentioned in the 
Office Action, Applicants submit that the rejection of claims 34, 38, 41 and 45 under § 
103 is improper. 

17 

PAGE 19120 ' RCVD AT 7/19/2005 3:25:16 PM [Eastern Daylight Time] ' SVR:USPTO-EFXRF-6f33 * DNIS:2738300 * CS1D:8324462424 * DURATION (miM$):07-20 



07/19/2005 13:29 8324462424 



WONG CABELLO 



PAGE 20 



Application No. 09/872,412 
Amendment Dated: July 19, 2005 
Reply to Office Action of April 19, 2005 



Applicants respectfully submit that claims 34, 38, 41 and 45 are allowable. 



Based on the above remarks Applicants respectfully submit that all of the present 
claims are allowable. Reconsideration is respectfully requested. 



Wong, Cabello, Lutsch, 

Rutherford & Brucculeri, L.L.P. 
20333 SH249. Suite 600 
Houston, TX 77070 
832/446-2405 
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CONCLUSION 



Respectfully submitted, 





Keith Lutsch 
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